Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added SimDRCalorimeterHit for dual-readout #380

Open
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

wonyongc
Copy link

BEGINRELEASENOTES

  • Added SimDRCalorimeterHit for optical photon dual-readout. Records number of scintillation/Cerenkov photons per hit as well as the wavelength/timing bins.

ENDRELEASENOTES

@wonyongc
Copy link
Author

Hi,
I have been developing a full simulation for a segmented crystal ECAL (CalVision/MAXICC collaborations) and am now submitting PRs to get the simulation into key4hep.
I needed to make a new datatype to store the scintllation/cerenkov hit information. So far I have simply extended the edm4hep schema with a custom 'edm4dr' schema in the simulation repo, but to merge into k4geo, it seems like it would be a better option (or the only one) to have this new schema merged into the main edm4hep.
Please let me know if I should take a different approach.
Thanks,
Wonyong

edm4hep.yaml Outdated
Comment on lines 413 to 416
- int32_t eta // detector cell eta
- int32_t phi // detector cell phi
- int32_t depth // detector cell depth
- int32_t system // detector cell system
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do you need these when there is already cellID?

edm4hep.yaml Outdated
Comment on lines 419 to 422
- std::array<int32_t, 6000> nwavelen_cer // number of cerenkov wavelength hits
- std::array<int32_t, 6000> nwavelen_scint // number of scint wavelength hits
- std::array<int32_t, 6000> ntime_cer // number of cerenkov time hits
- std::array<int32_t, 6000> ntime_scint // number of scint hits
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is stored in these arrays? What is the index? Why 6000?
This feels awfully inefficient.

@BrieucF
Copy link
Contributor

BrieucF commented Nov 25, 2024

Hi Wonyong, thanks.

Do I understand correctly that, for DRCrystals, SimCalorimeter hits are not an option? Is it because, unlike for DRFibers (see key4hep/k4geo#411), both C and S photons are produced by the same sensitive volume?

Is the need for storing wavelength coming from the fact that you need it for wavelength dependent effects in the digitization?

@wonyongc
Copy link
Author

Hi Brieuc,
Yes and yes. However, after discussing with Marco Lucchini we decided to keep this simpler for now and only include the counts and not the actual bins, which should also address Andre's comments. I will update this.

@wonyongc
Copy link
Author

Hi, I've updated the class wrt the comments above. Please take a look.

@SanghyunKo
Copy link

I was wondering whether we could just use two collections (one for the scintillation, one for the cherenkov channel) instead of implementing the dedicated data format (though I also opt to include the time information to the SimCalorimeterHit on par with the RawCalorimeterHit)

@tmadlener
Copy link
Contributor

I was wondering whether we could just use two collections (one for the scintillation, one for the cherenkov channel)

If that would be possible then I think that would be the easiest solution. Do you already have some digitization code, where it could be exercises how workable that solution actually is there?

(though I also opt to include the time information to the SimCalorimeterHit

We already discussed adding a time field to the SimCalorimeterHit in #147 without coming to a real conclusion in the end.

The main open question at that point was, what should be stored in the time field for the SimCalorimeterHit? Since there are probably several contributions to one hit, it's not entirely obvious which one of those it should be. If there is a choice that works for the majority of cases then we could maybe add that and clearly document which time should be stored there. However, that will also mean that the sensitive action (or the EDM4hep output?) would be responsible for filling that information appropriately.

- uint64_t cellID // detector cellID
- float energy [GeV] // energy of the hit
- edm4hep::Vector3f position [mm] // position of the calorimeter cell in world coords
- int32_t nCerenkovProd // number of cerenkov photons produced
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why produced photons? Why not recorded photons? Similar to having the avg arrival time of photons recorded in the time fields?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a SIM level object, I guess we should leave the possibility to treat effects such as efficiency in a subsequent digitizer (though it is indeed sometimes interesting to leak part of the digitization in the SDAction)

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But then the tAvg should also come from the digitiser and not be calculated here already?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some input from side. Our idea here is to have a first functional simulation which is a sufficiently good representation of the detector performance. The definition of the technology is still being matter of R&D and thus we are not ready yet to work on the digitization part. At this first stage, in our opinion, the most efficient approach (also from the computational time point of view) is to factorize the simulation of energy deposition part from that of optical photon tracing, SiPM and electronics.
From the former we need:

  • number of cherenkov photons produced (we can then apply offline, at the reconstruction level a scaling on this number which takes into account the light collection efficiency, i.e. light tracing aspects)
  • amount of energy deposited in each calorimetric cell

For what concerns the time stamp it is often sufficient to save the average time of all hits inside a certain calorimetric cell (possibly weighed with the energy of each hit). This is for our calorimeter a sufficiently good approximation of the time information we can extract with a realistic system (possibly after applying a resolution smearing).

It is to early to have a realistic implementation of the digitizer step in my opinion because of two reasons:

  • we want to explore different configurations and for this it is more convenient to apply "digitization" effects offline
  • simulation of optical photons is very time consuming so we are looking into a way to parametrize all optical aspects as much as possible (based on standalone Geant4 studies)

Concerning having separate collections for the scintillation and cherenkov photons this is also possible I believe. However, the difference with respect to the dual-readout fiber calorimeter is that in our case we have a complete duplications of hits since the cherenkov photons are always produced in the same volumes as that of other hits. Having two separate collections looked like redundant (I don't know about the impact on data size). For each hit in a certain calorimetric cell we always have both scintillation and cherenkov non-zero signals. If we use two separate collections we will have to match one-by-one all hits at the reconstruction level.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants